A few usefull things to consider using when your map is still lagging to much is the use of the following things

env_fog_controller The env_fog_controller is an entity that makes fog, but its most appreciated function is the fact you can set a maximum visible distace. In other words, everything more that so many units from the player will not be drawn. The fog can be used to mask this clipping, so players will think you made a nice map with fog for a nice effect, but actually you were trying to hide your bad optimizing skills...
Just place the env_fog_controller anywhere in your map, and enter the "fog start" and "fog end" values. Everything further away than the "fog end" value from the player will not be drawn.
For optimal effect, make sure the primairy fog color is whitish (its always like that) and that the primairy color is more blended with your skycolor. For instance, if your sky is yellow, make the secondairy fog color yellow-whitish, and if your skycolor is blue, make the secondairy fog color blue-whitish.

You can offcourse google some pics of fog to find out what color to make it. Fog in England is always grey, evening fog darkblueish, etc. You can even use yellow for as if it was dust in a de_dust map. Offcourse if your map isn't based on our earthly athmosphere, make up your own colors :) .
Experiment to find the values that suit your map best. You may need to find a 'foggy' skybox to suit your map best. Sometimes fog just doesn't fit the map though, can't help that.

Also, when you are using a 3d skybox, make sure you set the same fog properties in the sky_camera entity, or youll see strange effects with near buildings being fogged and far away buildings being completely visible.

fade-properties When you have helpers turned on in Hammer ( the diamond shaped button on the top toggles them ) you'll notice entities get circles. You can use these circles to denote at which distance your model entities should fade out ( inner circle ) and dissappear totally ( outer circle ). These circles correspond with the "start fade distance" and "end face ditance" properties of the model-based entities.
Few words of warnings:

1) If you set the fade-distances too low, the object wouldn't be visible when you should see them. This also happens when you accidentally select the circles instead of something else and make then really small. Because of that its best to hide helpers as long as you don't use them.
To reset the distances, go to the properties of the entity and make sure "start fade dist" equals -1, "end fade dist" equals 0 and "fade scale" equals 1.

2) static entities can be invisible when the player is out of its area ( and out of the room ) but when dealing with moving entities remember they may be brought to open area's where they can't be visible while they should.

3) You only gain performance outside the "end fade dist", fading entities cost just as much as (even slightly more than) normal ones.

4) On machines running DirectX level 7, the props will fade earlier than the values set in the entity to further improve rendering speed. This can be controlled on a per-MOD basis by creating a "dxsupport.cfg" file for your mod and specifying the values for the console variables "cl_detaildist" and "cl_detailfade" for the various dx support levels ( taken literally from www.Valve-erc.com ).

Fading objects is fun, but it may look rubbish. Since you only gain performance one the objects are completely invisible, there really isn't much you can gain.

Func_lod A func_lod is a brush-based entity that brings fade-distances to brushes. Just like the fade-distances does on models, this entity allows you to make brushes that disappears after a set distance. Great for outdoor optimization of details.
This is a real entity, so it won't seal leaks, and it costs more to render than func_detail.

Lightmaps To make vrad.exe take less time, you can increase the lightmap size. vrad.exe divides each face it has to light in squares, and then calculates for each square how much lighting it needs. Afterwards, all squares are faded into each other to create a nice fluent effect.
Reducing the size of these squares increases vrad.exe-times and qualitiy of lighting, increasing the size does the opposite.

You can specify the size of the lightmaps on a face by using the texture application tool. To the right of "texture shift" you'll see a box where you can input your custom lightmap scale. Default is 16 ( units per luxel ). Increasing this number will decrease the time vrad.exe takes, but also decrease lighting quality.

Because larger lightmaps mean less quality, only lower them on faces that are equally lit and have no shadows falling upon them, or faces players can hardly see ( for instance behind a model or far away faces ). The editor has a special view for lightmaps, in the 3d view click "camera" and select "lightmaps"

Also see the example map from Valve about lightmaps: "sourcesdk_content\hl2\mapsrc\sdk_lightmaps.vmf"

HDR Because HDR is only available for the somewhat more modern cards, there is no reason to not use it for optimization purposes, as all these cards should be fast enough to play your map with decent speeds anway. Just so you know.

Physics Having a lot of physics happening at the same time can really bring down any computer to it's knees. Make sure this never/rarely happens! For multiplayer games use prop_physics_multiplayer instead of prop_physics: you will get crappy/buggy physics, but atleast you got some more fps. And that is what it's about if you need these things. For the rest just use your mind and don't place 1000's of objects in a high-action-area. Be wise. For Counterstrike mappers: keep those physics objects away from bombsites if the explosion lags like usual. Only one thing sucks more than a smoothly running map with a laggy 'explosion de finale'.